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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above Is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 

- Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1 )□ Responsive to communication(s) filed on . 



2a)^ This action is FINAL. 2b)\Z\ This action is non-final. 

3) n Since this application is in condition for allowance except for fornnal nnatters, prosecution as to the nnerits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 
Disposition of Claims 

4) ^ Claim(s) 1-25 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) n Claim{s) is/are allowed. 

6) ^ Claim(s) 1-25 is/are rejected. 

7) ^ Claim(s) 1-25 is/are objected to. 

8) n Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 0 The specification is objected to by the Examiner. 

10) 0 The drawing(s) filed on is/are: a)n accepted or b)^ objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 

11) 0 The proposed drawing correction filed on is: a)n approved b)n disapproved by the Examiner. 

If approved, corrected drawings are required in reply to this Office action. 

12) 0 The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C, §§119 and 120 

13) 0 Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 

a)n All b)n Some * c)lJ None of: 

1 Certified copies of the priority documents have been received. 

2. n Certified copies of the priority documents have been received in Application No. . 

3. n Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

14) 0 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 1 19(e) (to a provisional application). 

a) □ The translation of the foreign language provisional application has been received. 

15) 0 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121. 
Attachment(s) 

1 ) □ Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) Paper No(s). . 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) 5) □ Notice of Infomnal Patent Application (PTO-152) 

3) □ Information Disclosure Statement(s) (PTO-1449) Paper No(s) . 6) □ Other: 
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Response to Amendment 



The reply to paper no. 2 filed on 15 January 2003 under 37 CFR 1.131 has been 
considered but is ineffective to overcome the Patrick et al. reference. 
Updated list of claims: 
1- Claim 8 and 18 (canceled) 

2" Claim 1 (added new): and transferring said pixel data to a memory controller using a 
memory controller client. 

3- Claim 2 (amended): writing pixel data to [a] said first memory location includes writing 
pixel data to a first virtual memory location. 

4- Claim 5 (amended): [entering an address] generating said memory address for [a] said 
second memory location includes transforming the addresses of said pixel data at said first 
memory location to addresses at said second memory location. 

5- Claim 9 (amended): writing said transformed pixel data fi-om said first memory location to 
said second memory location includes writing said pixel data fi-om [a] said first memory 
location associated with a first transfer fimction to [a] said second memory location associated 
with a second transfer fimction. 

6- Claim 11 (added new): and transferring said pixel data to a memory controller using a 
memory controller client. 

7- Claim 19 (amended): storing instructions that enable the processor-based system to write 
said pixel data from a first memory location associated with [a] said first transfer fimction to [a] 
said second memory location associated with a second transfer fimction. 
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8- Claim 22 (amended): first memory controller client selectively forwards pixel data and 
addresses to one of a plurality of transfer functions and said second controller client receives 
pixel data with new addresses from [a] said plurality of transfer functions 

9- Claim 3,4,6,7,10,12-17,20,21 and 23-25 (original) 

Response to remarks on page 3: 

• In response to page 3, line 6, applicant's arguments do not comply with 37 CFR 1.1 1 1(c) 
because they do not clearly point out the patentable novelty which he or she thinks the 
claims present in view of the state of the art disclosed by the references cited or the 
objections made. Further, they do not show how the amendments avoid such references 
or objections. Applicant discloses that the limitation of claim 1 may enable applying 
transformations (data), without expHcitly using a fetch engine in the physical memory. 
Fetch engine (a command or program) is meaning to obtain data from previous stage; 
applicant is using writing/performing/generating and transferring commands. Applicant 
does not claim how the data is obtained? And also what does part of the method 
write/perform/generate and transfer command? Physical memory is considered as hard 
drives/memory chips/compact disks/tapes and memory management supports the 
mapping of virtual memory addresses to physical memory addresses. In most modem 
microcomputers, however, the memory management is built into the CPU chip. 

• Applicant does not explicitly specifying a run-time or real time process in the claim; 
however, the run-time and real time is not the main subject of the invention. The 
transformation and manipulation of data to or from memory locations are the main 
subject matter, which is using similar concept. 
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• In response to page 4, line 3, applicant does not explicitly specifying the advantages of 
claiming first and second memory locations, because the amount of addressable location 
can be divided into first, second and etc. locations in memory. The applicant does not 
explicitly specifying how the data is transferred, but specifying multiple transformations 
can be applied to data before transferring. 

• Li response to page 4, line 9, applicant's argument that the references fail to show 
certain features of applicant's invention, it is noted that the features upon which 
applicant relies (i.e., writing of transformed data from one memory location to another 
memory location without depending upon the memory controller is not anticipated) are 
not recited in the rejected claim(s). Although the claims are interpreted in light of the 
specification, limitations from the specification are not read into the claims. See In re 
Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

• In response to page 4, line 17, applicant's arguments do not comply with 37 

CFR 1.1 1 1(c) because they do not clearly point out the patentable novelty which he or 
she thinks the claims present in view of the state of the art disclosed by the references 
cited or the objections made. Further, they do not show how the amendments avoid such 
references or objections. 

• Patrick illustrates in Fig. 1 that control unit device in which one or more of these parts 
of the CPU are integrated together, such as in a microprocessor. Moreover, the number 
and arrangement of the elements of the computer system may be varied from what is 
shown and described in ways known in the art. 
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• In response to page 4, line 23, applicant's arguments do not comply with 37 

CFR 1 . 1 1 1 (c) because they do not clearly point out the patentable novelty which he or 
she thinks the claims present in view of the state of the art disclosed by the references 
cited or the objections made. Further, they do not show how the amendments avoid such 
references or objections. 

• Patrick discloses in (col. 6, lines 48-62) when implemented within a function, bit 
compiler 58 see Fig. 2 requires the following information: (1) the addresses of the start 
of the source and destination bitmaps; (2) the x,y pixel coordinates designating the 
upper-left point of the rectangle to be transferred (from which the starting address of 
the data block may be determined); (3) the width and height of the rectangle to be 
transferred in pixels (from which the number of bytes in the data block may be 
determined); (4) the x,y coordinates in pixels designating the upper-left location in the 
destination where the source rectangle should be transferred to; and (5) a ROP code for 
how to combine the source and destination pixels with a pattem when doing the transfer 
Bit compiler 58 then generates code to transfer the data block from a source bitmap to a 
rectangle in the destination bitmap. Note: the number and arrangement of the elements 
of the computer system may be varied. 
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Claim Rejections - 35 USC §102 



(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

Claims 1-25 rejected under 35 U.S.C. 102(b) as being anticipated by Patrick et al. US 
patent 5,706,483 published date of Jan. 6, 1998, and filling date of Dec. 13, 1994. 
1. Claim 1, 

Patrick et al., hereinafter Patrick, shows a method comprising "writing pixel data to a first 
memory location", see disclosure in (Col. 6, lines 15-35) the following example that provides, 
what is involved in the block transfer of bytes from a source to a destination in memory. 
Patrick also shows "performing a first pixel transformation at said first memory location"; see Fig. 3 is a 
diagram showing an 8(1, 16, 32) bit per pixel bitmap at a source (a "source bitmap or first 
memory location") for transfer to an 8 bpp bitmap at a destination (a "destination bitmap or 
second memory location"). Patrick shows a complete illustration of "generating a memory address 
for a second memory location", see Fig. 3, that the source bitmap 60 is located at memory addresses 
0-499 (decimal) and the destination bitmap 62 is located at memory addresses 900-1399. A 
data block 61 for transfer is contained within a rectangle 60a in source bitmap 60 and consists 
of 15 bytes on each of 5 consecutive scan lines at the memory addresses given in the figure. 
Patrick demonstrates the transformation of data from first location to second location "writing 
said transformed pixel data from said first memory location to said second memory location; and transferring said 
pixel data to a memory controller using a memory controller client.", see Figs. 4-5, data block 61 is to be 
transferred to a similarly sized rectangle 62a in destination bitmap 62 at the memory addresses 
given in the figure. Each byte in data block 61 must be fetched (i.e., read) from a source 
address and written to a destination address. For example, the first byte of the data block has a 
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source address of 19. This byte is to be transferred to a destination address of 905. The next 
byte for transfer has a source address of 20 and a destination address of 906, and so forth. 

2. Claim 2, 

Patrick illustrated, "writing pixel data to said first memory location includes writing pixel 
data to a fu-st virtual memory location." in Fig. 1 , number 40, which is secondary storage 
area that can be apply as a virtual memory. (Virtual memory is: extension of the 
computer's internal memory, it considers locally or remotely). 

3. Claim 3, 

Patrick illustrated, "The method of claim 2 further including writing pixel data to a virtual memory 
location associated with a memory controller client that receives pixel data written to certain virtual addresses." in 
Fig. 1, number 40, which is secondary storage area that can be apply as a virtual memory. 
(Virtual memory is: extension of the computer's internal memory, it considers locally or 
remotely). 

4. Claim 4, 

Patrick demonstrated "causing an operating system to set aside virtual addresses for said 
memory controller client." And the step is inherent, because the operating system provides this 
options to the users to have more memory location as needed it, and these extended memory 
can be called virtual memory. 

5. Claim 5, 

Patrick demonstrated "generating said memory address for said second memory location 
includes transforming the addresses of said pixel data at said first memory location to addresses 
at said second memory location." And the step is inherent, because there must be an address to 
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be able to locate pixel or any other data when transferring pixel data to second memory 
location. 

6. Claim 6, 

Patrick demonstrated "determining the offset to each pixel data by subtracting a base address at 
said first memory location from the address of each pixel data." And the step is inherent, 
because each memory location has an address tagged to the pixel data, therefore, the pixel data 
can be referred to previous location as if the application (recording, viewing, storing) requires. 
The memory location will have more space by subtracting a base address from pixel data, but 
the pixel data can be viewed once and it depends on the application (player, display once) 
requirements. 

7. Claim 7, 

Patrick demonstrated "adding said offset to a base address of said second memory location." 
And the step is inherent, because the second memory location must have the base address of 
current location and plus previous parameters from first memory location (here is offset). 

8. Claim 8, 

Patrick demonstrated "writing said transformed pixel data fi'om said first memory location to 
said second memory location includes transferring said pixel data to a memory controller using 
a memory controller client." And the step is inherent, because Patrick shows in Fig. 1 the 
memory system number 30 that controls relocating the pixel data in memory areas. 

9. Claim 9, 

Patrick demonstrated "writing said transformed pixel data fi'om said first memory location to 
said second memory location includes writing said pixel data from said first memory location 
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associated with a first transfer function to said second memory location associated with a 
second transfer function." And the step is inherent, because, Patrick shows in Figs. 5 and 7 that 
flow charts of a method for compiling run-time code for a data block transfer. 

10. Claim 10, 

Patrick demonstrated "The method of claim 9 including transforming the addresses of said pixel 
data from addresses in a first virtual memory range associated with said first transfer function to 
memory addresses in a second virtual memory range associated with said second transfer 
function." And the step is inherent, because, Patrick shows in Figs. 5 and 7 that flow charts of a 
method for compiling run-time code for a data block transfer. 

11, Claim 11, 

Patrick discloses "write pixel data to a first memory location" in (Col. 6, lines 15-35) the 
following example that provides, what is involved in the block transfer of bytes fi-om a source 
to a destination in memory. Patrick discloses "perform a first pixel transformation at said first 
memory location" in Fig. 3 is a diagram showing an 8(1, 16, 32) bit per pixel bitmap at a source 
(a "source bitmap or first memory location") for transfer to an 8 bpp bitmap at a destination (a 
"destination bitmap or second memory location"). The source bitmap 60 is located at memory 
addresses 0-499 (decimal) and the destination bitmap 62 is located at memory addresses 900- 
1399. Patrick discloses "generate a memory address for a second memory location and write 
said transfonned pixel data from said first memory location to said second memory location; and transferring said 
pixel data to a memory controller using a memory controller client." A data block 61 for transfer is 

contained within a rectangle 60a in source bitmap 60 and consists of 15 bytes on each of 5 
consecutive scan lines at the memory addresses given in the figure. Data block 61 is to be 
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transferred to a similarly sized rectangle 62a in destination bitmap 62 at the memory addresses 
given in the figure. Each byte in data block 61 must be fetched (i.e., read) from a source 
address and written to a destination address. For example, the first byte of the data block has a 
source address of 19. This byte is to be transferred to a destination address of 905. The next 
byte for transfer has a source address of 20 and a destination address of 906, and so forth. 

12. Claim 12, 

Patrick illustrated "storing instructions that enable the processor-based system to write pixel 
data to a first virtual memory location." in Fig. 1, number 40, which is secondary storage area 
that can be apply as a virtual memory. (Virtual memory is: extension of the computer's internal 
memory, it considers locally or remotely). 

13. Claim 13, 

Patrick illustrated "storing instructions that enable the processor-based system to write pixel 
data to a virtual memory location associated with a memory controller client that receives pixel 
data written to certain virtual addresses." in Fig. 1, number 40, which is secondary storage area 
that can be apply as a virtual memory. (Virtual memory is: extension of the computer's internal 
memory, it considers locally or remotely). 

14. Claim 14, 

Patrick demonstrated "storing instructions that enable the processor-based system to cause an 
operating system to set aside virtual addresses 4 for said memory controller client." And the 
step is inherent, because the operating system provides this options to the users to have more 
memory location as needed it, and these extended memory can be called virtual memory. 
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15. Claim 15, 

Patrick demonstrated "storing instructions that enable the processor-based system to transform 
the addresses of pixel data at said first memory location to addresses at said second memory 
location." And the step is inherent, because there must be an address to be able to locate pixel 
or any other data when transferring pixel data to second memory location. 

16. Claim 16, 

Patrick demonstrated "storing instructions that enable the processor-based system to determine 
the offset to each pixel data by subtracting a base address at said first memory location from the 
address of each pixel data." And the step is inherent, because each memory location has an 
address tagged to the pixel data, therefore, the pixel data can be referred to previous location as 
if the application (recording, viewing, storing) requires. The memory location will have more 
space by subtracting a base address from pixel data, but the pixel data can be viewed once and 
it depends on the application (player, display once) requirements. 

17. Claim 17, 

Patrick demonstrated "storing instructions that enable the processor-based system to add said 
offset to a base address of said second memory location." And the step is inherent, because the 
second memory location must have the base address of current location and plus previous 
parameters from first memory location (here is offset). 

18. Claim 18, 

Patrick demonstrated "storing instructions that enable the processor-based system to transfer 
said pixel data to a memory controller using a memory controller client." And the step is 
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inherent, because Patrick shows in Fig. 1 the memory system number 30 that controls relocating 
the pixel data in memory areas. 

19. Claim 19, 

Patrick demonstrated "storing instructions that enable the processor-based system to write said 
pixel data from said first memory location associated with a first transfer function to said 
second memory location associated with a second transfer function." And the step is inherent, 
because, Patrick shows in Figs. 5 and 7 that flow charts of a method for compiling run-time 
code for a data block transfer. 

20. Claim 20, 

Patrick demonstrated "storing instructions that enable the processor-based system to transform 
the addresses of said pixel data from addresses in a first virtual memory range associated with 
said first transfer function to memory addresses in a second virtual memory range associated 
with said second transfer function." And the step is inherent, because, Patrick shows in Figs. 5 
and 7 that flow charts of a method for compiling run-time code for a data block transfer. 

21. Claim 21, 

Patrick demonstrated "A system comprising: a memory controller that receives pixel data and 
addresses; a first memory controller client that forwards pixel data and addresses to a first 
transfer function; and a second memory controller client that receives data from said first 
transfer function together with new addresses." in (Col. 6, lines 15-35) the following example 
that provides, what is involved in the block transfer of bytes from a source to a destination in 
memory. Fig. 3 is a diagram showing an 8(1, 16, 32) bit per pixel bitmap at a source (a "source 
bitmap or first memory location") for transfer to an 8 bpp bitmap at a destination (a "destination 



Application/Control Number: 09/584,604 Page 13 

Art Unit: 2672 

bitmap or second memory location"). The source bitmap 60 is located at memory addresses 0- 
499 (decimal) and the destination bitmap 62 is located at memory addresses 900-1399. A data 
block 61 for transfer is contained within a rectangle 60a in source bitmap 60 and consists of 15 
bytes on each of 5 consecutive scan lines at the memory addresses given in the figure. Data 
block 61 is to be transferred to a similarly sized rectangle 62a in destination bitmap 62 at the 
memory addresses given in the figure. Each byte in data block 61 must be fetched (i.e., read) 
firom a source address and written to a destination address. For example, the first byte of the 
data block has a source address of 19. This byte is to be transferred to a destination address of 
905. The next byte for transfer has a source address of 20 and a destination address of 906, and 
so forth. 

22. Claim 22, 

Patrick demonstrated "first memory controller client selectively forwards pixel data and 
addresses to one of a plurality of transfer functions and said second controller client receives 
pixel data with new addresses fi-om said plurality of transfer fiinctions." And the step is 
inherent, because, Patrick shows in Figs. 5 and 7 that flow charts of a method for compiling 
run-time code for a data block transfer. 

23. Claim 23, 

Patrick demonstrated "memory controller client writes the pixel data back to said memory 
controller." And the step is inherent, because this is the function of memory controller. 

24. Claim 24, 

Patrick demonstrated "a plurality of transfer fianctions, one of said transfer fimctions arranged 
to write output data to an address range of another transfer fimction." And the step is inherent, 
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because, Patrick shows in Figs. 5 and 7 that flow charts of a method for compiling run-time 
code for a data block transfer. 
25. Claim 25, 

Patrick demonstrated "transfer functions are associated with virtual memory address ranges." 
And the step is inherent, because the range of memory address must be known in order to be 
able to run the transfer function for any type of memory locations. 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 

MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 

MONTHS of the maihng date of this final action and the advisory action is not mailed until 

after the end of the THREE-MONTH shortened statutory period, then the shortened statutory 

period will expire on the date the advisory action is mailed, and any extension fee pursuant to 

37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 

however, will the statutory period for reply expire later than SIX MONTHS from the mailing 

date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Javid A Amini whose telephone number is 703-605-4248. The 
examiner can normally be reached on 8-4pm. If attempts to reach the examiner by telephone are 
unsuccessful, the examiner's supervisor, Michael Razavi can be reached on 703-305-4713. 
The fax phone numbers for the organization where this application or proceeding is assigned 
are 703-746-8705 for regular communications and 703-746-8705 for Afler Final 
communications. Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is 703-306-0377. 

Javid A Amini 
Examiner 
Art Unit 2672 



Javid Amini 
February 6, 2003 



